1. Field of the Invention
The present invention relates to systems and methods for providing a multi-tier enterprise level application. In particular, the present invention relates to systems and methods for providing an architecture and interface for delivering customizable music and advertisements to remote retail locations.
2. Background and Related Art
The emergence of the personal computer has provided a variety of computer system configurations. One such configuration is a client/server system, wherein the user interface runs on the client and the database is at the server. Such systems are typically two-tier configurations, wherein the business logic is performed at the clients and shared data is updated by sending streams of structured query language (“SQL”) to the server. The clients are modified to reflect new rules and conditions without modifying the server, as long as the server has access to the database (e.g., tables, views, etc.) used to perform the transactions. Commonly, the server of a two-tier configuration is referred to as a database server.
Problems currently exist with database servers. For example, the SQL corresponding to a business function is typically identical from call to call, with the exception of the data being updated or inserted. Accordingly, a database server spends valuable processing time parsing and re-parsing nearly identical SQL statements for each business function. Further, when a client or server falls behind on a software version, it typically must be shut down while it is being upgraded.
Another type of available architecture is an application server. In an application server environment business methods are run over the server and the client requests the server to execute the methods. Accordingly, the client and server typically use a protocol that represents a conversation at the level of business transactions instead of at the level of tables and rows. Accordingly, application servers often perform better than their database counterparts, but still suffer from problems with versioning.
Attempts have been made to enhance database and application systems by adding additional tiers to the architecture that place an intermediate component between the client and the server. One such attempt relates to a technique known as Enterprise Java Beans, which provides a framework for components that may be plugged into a server to extend the server's functionality. An Enterprise Java Bean client/server system configuration typically includes an Enterprise Java Bean component, container, object, and remote interface. An Enterprise Java Bean component executes within an Enterprise Java Bean container that in turn executes within an Enterprise Java Bean server. Client programs execute methods on remote enterprise Java Beans by way of an Enterprise Java Bean object. The object implements the remote interface of the Enterprise Java Bean component on the server. The remote interface represents the business methods for the Enterprise Java Bean component.
Implementation of an Enterprise Java Bean object is created by a co-generation tool that comes with the Enterprise Java Bean container. The object's interface is the remote interface of the Enterprise Java Bean component. The object (created by the container and tools associated with the container) and the Enterprise Java Bean component (created by the developer) implement the same remote interface. When the client calls a method on an Enterprise Java Bean object, the object method communicates with the remote Enterprise Java Bean container, requesting that the appropriate remote Enterprise Java Bean call the same method with the same arguments on the client's behalf.
Two types of Enterprise Java Beans currently exist, namely Session Beans and Entity Beans. Session Beans are typically not persistent and may not participate in transactions. An Entity Bean represents information persistently stored on a database. Entity Beans are associated with database transactions, provide data access to multiple users, and correspond to business objects that are typically mapped to one or more tables in a database. Since the data of an Entity Bean is persistently stored on a database, the Entity Beans survive server crashes.
While Enterprise Java Beans assist in avoiding the need to write and manage SQL statements by using container managed persistence, the use of the Enterprise Java Beans can prove to be complicated. For example, if an SQL needs to be changed, a developer may have to make the modification in a large complicated file. Thus, while techniques currently exist that are used to provide for multi-tier system configurations, challenges exist with the current techniques. Accordingly, it would be an improvement in the art to augment or even replace current techniques with other techniques to provide multi-tier system configurations.